home *** CD-ROM | disk | FTP | other *** search
- Path: news.lpr.carel.fi!usenet
- From: Ari Lukumies <aril@cmt.lpr.mail.carel.fi>
- Newsgroups: comp.lang.c
- Subject: Re: big endian, little endian
- Date: Thu, 18 Apr 1996 11:20:04 +0300
- Organization: Carelcomp Products
- Message-ID: <3175FB34.349@cmt.lpr.mail.carel.fi>
- References: <4ku9dm$t1t@news.ycc.yale.edu> <829609443snz@willen.demon.co.uk> <4l2ceg$ill@macondo.dmu.ac.uk>
- NNTP-Posting-Host: renoir.cclahti.carel.fi
- Mime-Version: 1.0
- Content-Type: text/plain; charset=us-ascii
- Content-Transfer-Encoding: 7bit
- X-Mailer: Mozilla 2.0 (WinNT; I)
-
- Andrew Buckby wrote:
- >
- > It the way inwhich number are stored in bytes. I may be wrong but I think that
- > Intel stores the highest bit on the right and the lowest on the left, 68000 and
- > most UNIX machines store it the other way with the highest bit on the left.
- >
- > intel 64 32 16 8 4 2 1 others 1 2 4 8 16 32 64
-
- Highest bit vs. lowest bit left or right? Geez, I thought we stored bytes... But,
- maybe it will be like this (hex 82, ie. 10000010 in bits):
-
- intel: 01000001 68k: 10000010
-
- Well? Actually, I've encountered a machine where this _seems_ to be true: Tandem
- NonStop series. The thing there, however, was the Tandem's way of numbering the
- bits, not their order:
-
- Bit numbers:
- intel: 76543210 Tandem: 01234567
- 0x82: 10000010 10000010
-
- Whether they were stored little or big-endian here, didn't matter. What mattered was
- what bit number you used (in source code) if you wanted to set, say, the bit that
- would alter 0x82 to 0x86.
-
- Later,
- AriL
- --
- All my opinions are mine and mine alone.
-